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Abstract 


The IETF TRILL (Transparent Interconnection of Lots of Links) 
protocol provides support for flow-level multipathing for both 
unicast and multi-destination traffic in networks with arbitrary 
topology. Active-active access at the TRILL edge is the extension of 
these characteristics to end stations that are multiply connected to 
a TRILL campus as discussed in RFC 7379. In this document, the edge 
RBridge (Routing Bridge, or TRILL switch) group providing active- 
active access to such an end station is represented as a virtual 
RBridge. Based on the concept of the virtual RBridge, along with its 
pseudo-nickname, this document specifies a method for TRILL active- 
active access by such end stations. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7781. 
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Les 


Introduction 


The IETF TRILL (Transparent Interconnection of Lots of Links) 
protocol [RFC6325] provides optimal pair-wise data frame forwarding 
without configuration, safe forwarding even during periods of 
temporary loops, and support for multipathing of both unicast and 
multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] 
[RFC7176] link-state routing and encapsulating traffic using a header 
that includes a Hop Count. Devices that implement TRILL are called 
RBridges (Routing Bridges) or TRILL switches. 


In the base TRILL protocol, an end node can be attached to the TRILL 
campus via a point-to-point link or a shared link such as a bridged 
LAN (Local Area Network). Although there might be more than one edge 
RBridge on a shared link, to avoid potential forwarding loops, one 
and only one of the edge RBridges is permitted to provide forwarding 
service for end-station traffic in each VLAN (Virtual LAN). That 
RBridge is referred to as the Appointed Forwarder (AF) for that VLAN 
on the link [RFC6325] [RFC6439]. However, in some practical 
deployments, to increase the access bandwidth and reliability, an end 
station might be multiply connected to several edge RBridges, and all 
of the uplinks are handled via a Local Active-Active Link Protocol 
(LAALP [RFC7379]) such as Multi-Chassis Link Aggregation (MC-LAG) or 
Distributed Resilient Network Interconnect (DRNI) [802.1AX]. In this 
case, it is required that traffic can be ingressed into, and egressed 
from, the TRILL campus by any of the RBridges for each given VLAN. 
These RBridges constitute an Active-Active Edge (AAE) RBridge group. 


With an LAALP, traffic with the same VLAN and source Media Access 
Control (MAC) address but belonging to different flows will 
frequently be sent to different member RBridges of the AAE group and 
then ingressed into the TRILL campus. When an egress RBridge 
receives such TRILL Data packets ingressed by different RBridges, it 
learns different correspondences between a {Data Label and 

MAC address} and nickname continuously when decapsulating the packets 
if it has data-plane address learning enabled. This issue is known 
as "MAC address flip-flopping"; it makes most TRILL switches behave 
badly and causes the returning traffic to reach the destination via 
different paths, resulting in persistent reordering of the frames. 
In addition to this issue, other issues, such as duplicate egressing 
and loopback of multi-destination frames, may also disturb an end 
station multiply connected to the member RBridges of an AAE group 
[RFC7379]. 


This document addresses the AAE issues of TRILL by specifying how 
members of an edge RBridge group can be represented by a virtual 

RBridge (RBv) and assigned a pseudo-nickname. A member RBridge of 
such a group uses a pseudo-nickname instead of its own nickname as 
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the ingress RBridge nickname when ingressing frames received on 
attached LAALP links. Other methods are possible: for example, the 
specification in this document and the specification in [RFC7782] 
could be simultaneously deployed for different AAE groups in the same 
campus. If the method defined in [RFC7782] is used, edge TRILL 
switches need to support the capability indicated by the Capability 
Flags APPsub-TLV as specified in Section 4.2 of [RFC7782]. If the 
method defined in this document is adopted, all TRILL switches need 
to support the Affinity sub-TLV defined in [RFC7176] and [RFC7783]. 
For a TRILL campus that deploys both of these AAE methods, TRILL 
switches are required to support both methods. However, it is 
desirable to only adopt one method in a TRILL campus so that the 
operating expense, complexity of troubleshooting, etc., can be 
reduced. 


The main body of this document is organized as follows: 


o Section 2 provides an overview of the TRILL active-active access 
issues and the reason that a virtual RBridge (RBv) is used to 
resolve the issues. 


o Section 3 describes the concept of a virtual RBridge (RBv) and its 
pseudo-nickname. 


o Section 4 describes how edge RBridges can support an RBv 
automatically and get a pseudo-nickname for the RBv. 


o Section 5 discusses how to protect multi-destination traffic 
against disruption due to Reverse Forwarding Path (RPF) check 
failure, duplication, forwarding loops, etc. 


o Section 6 covers the special processing of native frames and TRILL 
Data packets at member RBridges of an RBv (also referred to as an 
Active-Active Edge (AAE) RBridge group). 


o Section 7 describes the MAC information synchronization among the 
member RBridges of an RBv. 


o Section 8 discusses protection against downlink failure at a 
member RBridge. 


o Section 9 lists the necessary TRILL code points and data 
structures for a pseudo-nickname AAE RBridge group. 
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1.1. Terminology and Acronyms 


This document uses the acronyms and terms defined in [RFC6325] and 
[RFC7379], as well as the following additional acronyms: 


AAE: Active-active Edge RBridge group. A group of edge RBridges to 
which at least one Customer Equipment (CE) node is multiply 
attached with an LAALP. AAE is also referred to as "edge group" 
or "virtual RBridge" in this document. 


Campus: A TRILL network consisting of TRILL switches, links, and 
possibly bridges bounded by end stations and IP routers. For 


TRILL, there is no "academic" implication in the name "campus". 


CE: Customer Equipment (end station or bridge). The device Can be 
either physical or virtual equipment. 


Data Label: VLAN or Fine-Grained Label (FGL). 

DF: Designated Forwarder. 

DRNI: Distributed Resilient Network Interconnect. A link aggregation 
specified in [802.1AX] that can provide an LAALP between (a) one, 


two, or three CEs and (b) two or three RBridges. 


E-L1FS: Extended Level 1 Flooding Scope [RFC7356]. 


ESADI: End-Station Address Distribution Information. 


FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained 
Label [RFC7172]. 


LAALP: Local Active-Active Link Protocol [RFC7379], e.g., MC-LAG 
or DRNI. 


MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions of 
Link Aggregation [802.1AX] that can provide an LAALP between one 
CE and two or more RBridges. 


OE-flag: A flag used by a member RBridge of a given LAALP to tell 
other edge RBridges of this LAALP whether this LAALP is willing to 
share an RBv with other LAALPs that multiply attach to the same 
set of edge RBridges as the given LAALP does. When this flag for 
an LAALP is 1, it means that the LAALP needs to be served by an 
RBv by itself and is not willing to share, that is, it should 
Occupy an RBv Exclusively (OE). 
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RBv: Virtual RBridge. An alias for "active-active edge RBridge 
group" in this document. 


vDRB: The Designated RBridge in an RBv. It is responsible for 
deciding the pseudo-nickname for the RBv. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Overview 


To minimize impact during failures and maximize available access 
bandwidth, Customer Equipment (referred to as "CE" in this document) 
may be multiply connected to the TRILL campus via multiple edge 
RBridges. 


Figure 1 shows such a typical deployment scenario, where CEl attaches 
to RB1, RB2, ... RBk and treats all of the uplinks as an LAALP 
bundle. RB1, RB2, ... RBk then constitute an AAE RBridge group for 
CEl in this LAALP. Even if a member RBridge or an uplink fails, CEl 
will still get frame forwarding service from the TRILL campus if 
there are still member RBridges and uplinks available in the AAE 
group. Furthermore, CEl can make flow-based load balancing across 
the available member links of the LAALP bundle in the AAE group when 
it communicates with other CEs across the TRILL campus [RFC7379]. 
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| 
es, 4+------ + Ho + 
| (RB1) | | (RB2) | | (RBk) | 
4+------ + 4+------ + +------ + 
-l |-- | |- 
Mr | || 
DE | ll + | 
| +-|---|----- + 0 AAA + | 
4------------------ + 
LAALP1--> ( l, (| F <--LAALPn 
4+------- + 4+------- + 
| CE1 | | CEn | 
4+------- + 4+------- + 


Figure 1: Active-Active Connection to TRILL Edge RBridges 


By design, an LAALP (say LAALP1) does not forward packets received on 
one member port to other member ports. As a result, the TRILL Hello 
messages sent by one member RBridge (say RB1) via a port to CEl will 
not be forwarded to other member RBridges by CEl. That is to say, 
member RBridges will not see each other’s Hellos via the LAALP. So, 
every member RBridge of LAALP1 thinks of itself as Appointed 
Forwarder for all VLANs enabled on an LAALP1 link and can 
ingress/egress frames simultaneously in these VLANs [RFC6439]. 


The simultaneous flow-based ingressing/egressing can cause some 


problems. For example, simultaneous egressing of multi-destination 
traffic by multiple member RBridges will result in frame duplication 
at CEl (see Section 3.1 of [RFC7379]); simultaneous ingressing of 


frames originated by CEl for different flows in the same VLAN with 
the same source MAC address will result in MAC address flip-flopping 
at remote egress RBridges that have data-plane address learning 
enabled (see Section 3.3 of [RFC7379]). The flip-flopping would in 
turn cause packet reordering in reverse traffic. 
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Edge RBridges learn correspondences between a (Data Label and MAC 
address) and nickname by default when decapsulating TRILL Data 
packets (see Section 4.8.1 of [RFC6325], as updated by [RFC7172]). 
Assuming that the default data-plane learning is enabled at edge 
RBridges, MAC address flip-flopping can be solved by using a virtual 
RBridge together with its pseudo-nickname. This document specifies a 
way to do so. 


3. Virtual RBridge and Its Pseudo-Nickname 


A virtual RBridge (RBv) represents a group of edge RBridges to which 
at least one CE is multiply attached using an LAALP. More precisely, 
it represents a group of ports on the edge RBridges providing 
end-station service and the service provided to the CE(s) on these 
ports, through which the CE(s) is multiply attached to the TRILL 
campus using LAALP(s). Such end-station service ports are called RBv 
ports; in contrast, other access ports at edge RBridges are called 
regular access ports in this document. RBv ports are always 

LAALP connecting ports, but not vice versa (see Section 4.1). For an 
edge RBridge, if one or more of its end-station service ports are 
ports of an RBv, that RBridge is a member RBridge of that RBv. 


For the convenience of description, a virtual RBridge is also 
referred to as an Active-Active Edge (AAE) group in this document. 
In the TRILL campus, an RBv is identified by its pseudo-nickname, 


which is different from any RBridge’s regular nickname(s). An RBv 
has one and only one pseudo-nickname. Each member RBridge (say RBl, 
RB2 ..., RBk) of an RBv (say RBvn) advertises RBvn’s pseudo-nickname 


using a Nickname sub-TLV in its TRILL IS-IS LSP (Link State PDU) 
[RFC7176] and SHOULD do so with maximum priority of use (0xFF), along 
with their regular nickname (s). (Maximum priority is recommended to 
avoid the disruption to an AAE group that would occur if the nickname 
were taken away by a higher-priority RBridge.) Then, from these 
LSPs, other RBridges outside the AAE group know that RBvn is 
reachable through RB1 to RBk. 


A member RBridge (say RBi) loses its membership in RBvn when its last 
port in RBvn becomes unavailable due to failure, reconfiguration, 
etc. RBi then removes RBvn's pseudo-nickname from its LSP and 
distributes the updated LSP as usual. From those updated LSPs, other 
RBridges know that there is no path to RBvn through RBi now. 


When member RBridges receive native frames on their RBv ports and 
decide to ingress the frames into the TRILL campus, they use that 
RBv’s pseudo-nickname instead of their own regular nicknames as the 
ingress nickname to encapsulate them into TRILL Data packets. So, 
when these packets arrive at an egress RBridge, even if they are 
originated by the same end station in the same VLAN but ingressed by 
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different member RBridges, no address flip-flopping is observed on 
the egress RBridge when decapsulating these packets. (When a member 
RBridge of an AAE group ingresses a frame from a non-RBv port, it 
still uses its own regular nickname as the ingress nickname.) 


Since an RBv is not a physical node and no TRILL frames are forwarded 
between its ports via an LAALP, pseudonode LSP(s) MUST NOT be created 
for an RBv. An RBv cannot act as a root when constructing 
distribution trees for multi-destination traffic, and its 
pseudo-nickname is ignored when determining the distribution tree 
root for the TRILL campus [RFC7783]. So, the tree root priority of 
the RBv’s nickname MUST be set to 0, and this nickname MUST NOT be 
listed in the "s" nicknames (see Section 4.5 of [RFC6325]) by the 
RBridge holding the highest-priority tree root nickname. 


NOTE: In order to reduce the consumption of nicknames, especially in 
a large TRILL campus with lots of RBridges and/or active-active 
accesses, when multiple CEs attach to exactly the same set of edge 
RBridges via LAALPs, those edge RBridges should be considered a 
single RBv with a single pseudo-nickname. 


4. Auto-Discovery of Member RBridges 


Edge RBridges connected to a CE via an LAALP can automatically 
discover each other with minimal configuration through the exchange 
of LAALP connection information. 


From the perspective of edge RBridges, a CE that connects to edge 
RBridges via an LAALP can be identified by the ID of the LAALP that 
is unique across the TRILL campus (for example, the MC-LAG or DRNI 
System ID [802.1AX]), which is referred to as an LAALP ID in this 
document. On each such edge RBridge, the access port to such a CE is 
associated with an LAALP ID for the CE. An LAALP is considered valid 
on an edge RBridge only if the RBridge still has an operational 
downlink to that LAALP. For such an edge RBridge, it advertises a 
list of LAALP IDs for its valid local LAALPs to other edge RBridges 
via its E-L1FS FS-LSP (s) [RFC7356] [RFC7780]. Based on the LAALP IDs 
advertised by other RBridges, each RBridge can know which edge 
RBridges could constitute an AAE group (see Section 4.1 for more 
details). One RBridge is then elected from the group to allocate an 
available nickname (the pseudo-nickname) for the group (see 

Section 4.2 for more details). 
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4.1. Discovering Member RBridge for an RBv 


Take Figure 2 as an example, where CEl and CE2 multiply attach to 
RB1, RB2, and RB3 via LAALP1 and LAALP2, respectively; CE3 and CE4 
attach to RB3, and RB4 via LAALP3 and LAALP4, respectively. Assume 
that LAALP3 is configured to occupy a virtual RBridge by itself. 


/ \ 
| TRILL Campus | 
\ / 
| | Li ol 
#------- + | |  +---------- + 
| | | | 
4+------- + 4+------- + 4+------- + 4+------- + 
| RB1 | | RB2 | | RB3 | | RB | 
4+------- + 4+------- + 4+------- + 4+------- + 
| | la ll IA | | 
| e |--+ | +------- |-+ | #------- [+ | 
| +---------- + | || i | | 
| 4+-----------|-|-]------- + #------- + 
| AN | p 
LAALP1->(| | |) LAALP2->(| | |) LAALP3->(| |) LAALP4->(| |) 
4+------- + 4+------- + 4+------- + 4+------- + 
| CE1 | | CE2 | | ee | | era | 
4+------- + 4+------- + 4+------- + 4+------- + 


Figure 2: Different LAALPs to TRILL Campus 


RB1 and RB2 advertise {LAALP1, LAALP2} in the PN-LAALP-Membership 
APPsub-TLV (see Section 9.1 for more details) via their TRILL E-L1FS 
FS-LSPs, respectively; RB3 announces {LAALP1, LAALP2, LAALP3, 
LAALP4}, and RB4 announces {LAALP3, LAALP4}, respectively. 
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An edge RBridge is called an "LAALP related RBridge" if it has at 
least one LAALP configured on an access port. On receipt of the 
PN-LAALP-Membership APPsub-TLVs, RBn ignores them if it is not an 
LAALP related RBridge; otherwise, RBn SHOULD use the LAALP 
information contained in the sub-TLVs, along with its own 
PN-LAALP-Membership APPsub-TLVs, to decide which RBv(s) it should 
join and which edge RBridges constitute each such RBv. Based on the 
information received, each of the four RBridges knows the following: 


LAALP ID OE-flag Set of edge RBridges 
LAATP1 0 (RB1, RB2, RB3) 
LAALP2 0 (RB1, RB2, RB3) 
LAALP3 1 {RB3, RB4} 

LAALP4 0 {RB3, RB4} 


where the OE-flag indicates whether a given LAALP is willing to share 
an RBv with other LAALPs that multiply attach to the same set of edge 
RBridges as the given LAALP does. 


For an LAALP (for example, LAALP3), if its OE-flag is one, it means 
that LAALP3 does not want to share, so it MUST Occupy an RBv 


Exclusively (OE). Support of OE is optional. RBridges that do not 
support OE ignore the OE-flag and act as if it were zero (see 
Section 11 ("Configuration Consistency")). 


Otherwise, the LAALP (for example, LAALP1) will share an RBv with 
other LAALPs if possible. By default, this flag is set to zero. For 
an LAALP, this flag is considered 1 if any edge RBridge advertises it 
as (value) 1 (see Section 9.1). 


In the above table, there might be some LAALPs that attach to a 
single RBridge due to misconfiguration or link failure, etc. Those 
LAALPs are considered to be invalid entries. Each of the LAALP 
related edge RBridges then performs the following algorithm to decide 
which valid LAALPs can be served by an RBv. 


Step 1: Take all the valid LAALPs that have their OE-flags set to 
1 out of the table and create an RBv for each such LAALP. 


Step 2: Sort the valid LAALPs left in the table in descending 
order based on the number of RBridges in their associated set 
of multihomed RBridges. If several LAALPs have the same number 
of RBridges, these LAALPs are then ordered in ascending order 
in the proper places of the table, based on their LAALP IDs 
considered to be unsigned integers. (For example, in the above 
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table, both LAALP1 and LAALP2 have three member RBridges, 
assuming that the LAALP1 ID is smaller than the LAALP2 ID, so 
LAALP1 is followed by LAALP2 in the ordered table.) 


Step 3: Take the first valid LAALP (say LAALP_i) with the maximum 
set of RBridges, say S_i, out of the table and create a new RBv 
(say RBv_i) for it. 


Step 4: Walk through the remaining valid LAALPs in the table one 
by one, pick up all the valid LAALPs whose sets of multi-homed 
RBridges contain exactly the same RBridges as that of LAALP_i, 
and take them out of the table. Then, appoint RBv_i as the 
servicing RBv for those LAALPs. 


Step 5: Repeat Steps 3 and 4 for any LAALPs left, until all the 
valid entries in the table are associated with an RBv. 


After performing the above steps, all the four RBridges know that 
LAALP3 is served by an RBv, say RBvl, which has RB3 and RB4 as member 
RBridges; LAALP1 and LAALP2 are served by another RBv, say RBv2, 
which has RB1, RB2, and RB3 as member RBridges; and LAALP4 is served 
by RBv3, which has RB3 and RB4 as member RBridges, shown as follows: 


RBv Serving LAALPs Member RBridges 
RBv1 { LAALP 3 } {RB3, RB4} 
RBv2 {LAALP1, LAALP2} (RB1, RB2, RB3} 
RBv3 { LAALP 4 } {RB3, RB4} 


In each RBv, one of the member RBridges is elected as the vDRB 
(referred to in this document as the Designated RBridge of the RBv). 
Then, this RBridge picks up an available nickname as the 
pseudo-nickname for the RBv and announces it to all other member 
RBridges of the RBv via its TRILL E-L1FS FS-LSPs (refer to 

Section 9.2 for the relative extended sub-TLVs). 


4.2. Selection of Pseudo-Nickname for an RBv 


As described in Section 3, in the TRILL campus, an RBv is identified 
by its pseudo-nickname. In an AAE group, one member RBridge is 
elected for the duty of selecting a pseudo-nickname for this RBv; 
this RBridge will be the vDRB. The winner in the group is the 
RBridge with the largest IS-IS System ID considered to be an unsigned 
integer. Then, based on its TRILL IS-IS link-state database and the 
potential pseudo-nickname(s) reported in the PN-LAALP-Membership 
APPsub-TLVs by other member RBridges of this RBv (see Section 9.1 for 
more details), the vDRB selects an available nickname as the 
pseudo-nickname for this RBv and advertises it to the other RBridges 
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via its E-L1FS FS-LSP (s) (see Section 9.2 and [RFC7780]). Except as 
provided below, the selection of a nickname to use as the 
pseudo-nickname follows the usual TRILL rules given in [RFC6325], as 
updated by [RFC7780]. 


To reduce the traffic disruption caused by the changing of nicknames, 
if possible, the vDRB SHOULD attempt to reuse the pseudo-nickname 
recently used by the group when selecting nickname for the RBv. To 
help the vDRB to do so, each LAALP related RBridge advertises a 
reusing pseudo-nickname for each of its LAALPs in its 
PN-LAALP-Membership APPsub-TLV if it has used such a pseudo-nickname 
for that LAALP recently. Although it is up to the implementation of 
the vDRB as to how to treat the reusing pseudo-nicknames, the 
following are RECOMMENDED: 


o If there are multiple available reusing pseudo-nicknames that are 
reported by all the member RBridges of some LAALPs in this RBv, 
the available one that is reported by the largest number of such 
LAALPs is chosen as the pseudo-nickname for this RBv. If a tie 
exists, the reusing pseudo-nickname with the smallest value 
considered to be an unsigned integer is chosen. 


o If only one reusing pseudo-nickname is reported, it SHOULD be 
chosen if available. 


If there is no available reusing pseudo-nickname reported, the vDRB 
selects a nickname by its usual method. 


The selected pseudo-nickname is then announced by the vDRB to other 
member RBridges of this RBv in the PN-RBv APPsub-TLV (see 
Section 9.2). 


5. Distribution Trees and Designated Forwarder 


In an AAE group, as each of the member RBridges thinks it is the 
Appointed Forwarder for VLAN x, without changes made for 
active-active connection support, they would all ingress frames into, 
and egress frames from, the TRILL campus for all VLANs. For 
multi-destination frames, more than one member RBridge ingressing 
them may cause some of the resulting TRILL Data packets to be 
discarded due to failure of the Reverse Path Forwarding (RPF) check 
on other RBridges; for multi-destination traffic, more than one 
RBridge egressing it may cause local CE(s) to receive duplicate 
frames. Furthermore, in an AAE group, a multi-destination frame sent 
by a CE (say CEi) may be ingressed into the TRILL campus by one 
member RBridge, and another member RBridge will then receive it from 
the TRILL campus and egress it to CHi; this will result in loopback 
of the frame for CEi. These problems are all described in [RFC7379]. 
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In the following subsections, the first two issues are discussed in 
Sections 5.1 and 5.2, respectively; the third issue is discussed in 
Section 5.3. 


5.1. Different Trees for Different Member RBridges 


In TRILL, RBridges normally use distribution trees to forward 


multi-destination frames. (Under some circumstances, they can be 
unicast, as specified in [RFC7172].) An RPF check, along with other 
types of checks, is used to avoid temporary multicast loops during 
topology changes (Section 4.5.2 of [RFC6325]). The RPF check 


mechanism only accepts a multi-destination frame ingressed by an 
RBridge (say RBi) and forwarded on a distribution tree if it arrives 
at another RBridge (say RBn) on the expected port. If the frame 
arrives on any other port, the frame MUST be dropped. 


To avoid address flip-flopping on remote RBridges, member RBridges 
use the RBv’s pseudo-nickname instead of their regular nicknames as 
the ingress nickname to ingress native frames, including 
multi-destination frames. From the view of other RBridges, these 
frames appear as if they were ingressed by the RBv. When 
multi-destination frames of different flows are ingressed by 
different member RBridges of an RBv and forwarded along the same 
distribution tree, they may arrive at RBn on different ports. Some 
of them will violate the RPF check principle at RBn and be dropped, 
which will result in lost traffic. 


In an RBv, if a different member RBridge uses different distribution 
trees to ingress multi-destination frames, the RPF check violation 
issue can be fixed. The Coordinated Multicast Trees (CMT) document 
[RFC7783] proposes such an approach and makes use of the Affinity 
sub-TLV defined in [RFC7176] to tell other RBridges which trees a 
member RBridge (say RBi) may choose when ingressing multi-destination 
frames; all RBridges in the TRILL campus can then calculate RPF check 
information for RBi on those trees, taking the tree affinity 
information into account [RFC7783]. 


This document uses the approach proposed in [RFC7783] to fix the 


RPF check violation issue. Please refer to [RFC7783] for more 
details regarding this approach. 
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5.2. Designated Forwarder for Member RBridges 


Take Figure 3 as an example, where CEl and CE2 are served by an RBv 
that has RB1 and RB2 as member RBridges. In VLAN x, the three CEs 
can communicate with each other. 


/ VO += + 
| TRILL Campus |---| RBn 
\ +----- + 
| | 
+=---+ #------ + 
fates a de este 
RB1 RB2 
OO000000 | 0000000000000000 | 00000 
Oe ein ae sce + RBv FS Seas O= 
o | 0000 | 00000000000000000000l0l0 | 
| > “| | 
| | +--------- + +---------- + | 
(| |)<-LAALP1 (| |)<-LAALP2 | 
4+------- + 4+------- + 4+------- + 
| CE1l | | CE2 | | CE3 | 
4+------- + 4+------- + 4+------- + 


Figure 3: A Topology with Multihomed and Single-Homed CEs 


When a remote RBridge (say RBn) sends a multi-destination TRILL Data 
packet in VLAN x (or the FGL that VLAN x maps to, if the packet is 
FGL), both RB1 and RB2 will receive it. As each of them thinks it is 
the Appointed Forwarder for VLAN x, without changes made for 
active-active connection support, they would both forward the frame 
to CE1/CE2. As a result, CE1/CE2 would receive duplicate copies of 
the frame through this RBv. 


In another case, assume that CE3 is single-homed to RB2. When it 
transmits a native multi-destination frame onto link CE3-RB2 in 

VLAN x, the frame can be locally replicated to the ports to CE1/CE2, 
and also encapsulated into TRILL Data packet and ingressed into the 
TRILL campus. When the packet arrives at RB1 across the TRILL 
campus, it will be egressed to CE1/CE2 by RB1. CE1/CE2 then receives 
duplicate copies from RB1 and RB2. 
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In this document, the Designated Forwarder (DF) for a VLAN is 
introduced to avoid duplicate copies. The basic idea of the DF is to 
elect one RBridge per VLAN from an RBv to egress multi-destination 
TRILL Data traffic and replicate locally received multi-destination 
native frames to the CEs served by the RBv. 


Note that the DF has an effect only on the egressing/replicating of 
multi-destination traffic. It has no effect on the ingressing, 
forwarding, or egressing of unicast frames. Furthermore, the DF 
check is performed only for RBv ports, not on regular access ports. 


Each RBridge in an RBv elects a DF using the same algorithm; this 
guarantees that, per VLAN, the same RBridge is elected as the DF by 
all members of the RBv. 


If we assume that there are m LAALPs and k member RBridges in an RBv, 
then (1) each LAALP is referred to as "LAALPi", where 0 <= i < m, and 
(2) each RBridge is referred to as "RBj3", where 0 <= j < k. The DF 
election algorithm per VLAN is as follows: 


Step 1: For LAALPi, sort all the RBridges in numerically ascending 
order based on SHA-256 (System IDj | LAALP IDi) considered to be 
an unsigned integer, where SHA-256 is the hash function 
specified in [RFC6234], "System IDj" is the 6-byte IS-IS System 
ID of RBJ, wa means concatenation, and "LAALP IDi" is the 
LAALP ID for LAALPi. The System ID and LAALP ID are considered 
to be byte strings. In the case of a tie, the tied RBridges 
are sorted in numerically ascending order by their System IDs 
considered to be unsigned integers. 


Step 2: Each RBridge in the numerically sorted list is assigned a 
monotonically increasing number j, such that increasing number 
j corresponds to its position in the sorted list, i.e., the 
first RBridge (the one with the smallest SHA-256 (System ID | 
LAALP ID)) is assigned zero and the last is assigned k-1. 


Step 3: For each VLAN ID n, choose the RBridge whose number equals 
(n mod k) as the DF. 


Step 4: Repeat Steps 1-3 for the remaining LAALPs until there is a 
DF per VLAN per LAALP in the RBv. 
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For any multi-destination native frames of VLAN x that are received, 
if RBi is an LAALP attached RBridge, there are three cases where RBi 
replicates the multi-destination frame, as follows: 


1) Local replication of the frame to regular (non-AAE) access 
ports as per [RFC6325] (and [RFC7172] for FGL). 


2) RBv ports associated with the same pseudo-nickname as that of 
the incoming port, no matter whether RBi is the DF for the 
frame’s VLAN on the outgoing ports, except that the frame 
MUST NOT be replicated back to the incoming port. RBi cannot 
simply depend on the DF to forward the multi-destination frame 
back into the AAEs associated with the pseudo-nickname, as that 
would cause the source CE to get the frame back, which is a 
violation of basic Ethernet properties. The DF will not 
forward such a frame back into the AAE due to ingress nickname 
filtering as described in Section 5.3. 


3) RBv ports on which RBi is the DF for the frame’s VLAN while 
they are associated with different pseudo-nickname(s) than that 
of the incoming port. 


For any multi-destination TRILL Data packets that are received, RBi 
MUST NOT egress it out of the RBv ports where it is not the DF for 
the frame’s Inner.VLAN (or for the VLAN corresponding to the 
Inner.Label if the packet is an FGL one). Otherwise, whether or not 
to egress it out of such ports is further subject to the filtering 
check result of the frame’s ingress nickname on these ports (see 
Section 5.3). 


5.3. Ingress Nickname Filtering 


As shown in Figure 3, CEl may send multi-destination traffic in 
VLAN x to the TRILL campus via a member RBridge (say RB1). The 
traffic is then TRILL-encapsulated by RB1 and delivered through the 
TRILL campus to multi-destination receivers. RB2 may receive the 
traffic and egress it back to CEl if it is the DF for VLAN x on the 
port to LAALP1. The traffic then loops back to CEl (see Section 3.2 
of [RFC7379]). 


To fix the above issue, this document requires an ingress nickname 
filtering check. The idea is to check the ingress nickname of a 
multi-destination TRILL Data packet before egressing a copy of it out 
of an RBv port. If the ingress nickname matches the pseudo-nickname 
of the RBv (associated with the port), the filtering check should 
fail and the copy MUST NOT be egressed out of that RBv port. 
Otherwise, the copy is egressed out of that port if it has also 
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passed other checks, such as the Appointed Forwarder check described 
in Section 4.6.2.5 of [RFC6325] and the DF check described in 
Section 5.2. 


Note that this ingress nickname filtering check has no effect on the 
multi-destination native frames that are received on access ports and 
replicated to other local ports (including RBv ports), since there is 
no ingress nickname associated with such frames. Furthermore, for 
the RBridge regular access ports, there is no pseudo-nickname 
associated with them, so no ingress nickname filtering check is 
required on those ports. 


More details of data packet processing on RBv ports are given in the 
next section. 


6. TRILL Traffic Processing 


This section provides more details of native frame and TRILL Data 
packet processing as it relates to the RBv’s pseudo-nickname. 


6.1. Ingressing Native Frames 
When RB1 receives a unicast native frame from one of its ports that 


has end-station service enabled, it processes the frame as described 
in Section 4.6.1.1 of [RFC6325], with the following exception: 


o If the port is an RBv port, RB1 uses the RBv’s pseudo-nickname 
instead of one of its regular nickname(s) as the ingress nickname 
when doing TRILL encapsulation on the frame. 


When RB1 receives a native multi-destination (broadcast, 

unknown unicast, or multicast) frame from one of its access ports 
(including regular access ports and RBv ports), it processes the 
frame as described in Section 4.6.1.2 of [RFC6325], with the 
following exceptions: 


o If the incoming port is an RBv port, RBl uses the RBv’s 
pseudo-nickname instead of one of its regular nickname(s) as the 
ingress nickname when doing TRILL encapsulation on the frame. 
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o For the copies of the frame replicated locally to RBv ports, there 
are two cases, as follows: 


- If the outgoing port(s) is associated with the same 
pseudo-nickname as that of the incoming port but not with the 
same LAALP as the incoming port, the copies are forwarded out of 
that outgoing port(s) after passing the Appointed Forwarder 
check for the frame’s VLAN. That is to say, the copies are 
processed on such port(s), as discussed in Section 4.6.1.2 of 
[RFC6325]. 


- Else, the Designated Forwarder (DF) check is also made on the 
outgoing ports for the frame’s VLAN after the Appointed 
Forwarder check, and the copies are not output through any ports 
that failed the DF check (i.e., RB1 is not the DF for the 
frame's VLAN on the ports). Otherwise, the copies are forwarded 
out of the outgoing ports that pass both the Appointed Forwarder 
check and the DF check (see Section 5.2). 


For any such frames received, the MAC address information learned by 
observing it, together with the LAALP ID of the incoming port, SHOULD 
be shared with other member RBridges in the group (see Section 7). 


6.2. Egressing TRILL Data Packets 


This section describes egress processing of the TRILL Data packets 
received on an RBv member RBridge (say RBn). Section 6.2.1 describes 
the egress processing of unicast TRILL Data packets, and 

Section 6.2.2 specifies the egressing of multi-destination TRILL Data 
packets. 


6.2.1. Unicast TRILL Data Packets 


When receiving a unicast TRILL Data packet, RBn checks the egress 
nickname in the TRILL Header of the packet. If the egress nickname 
is one of RBn’s regular nicknames, the packet is processed as defined 
in Section 4.6.2.4 of [RFC6325]. 


If the egress nickname is the pseudo-nickname of a local RBv, RBn is 
responsible for learning the source MAC address, unless data-plane 
learning has been disabled. The learned {Inner.MacSA, Data Label, 
ingress nickname} triplet SHOULD be shared within the AAE group as 
described in Section 7. 
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The packet is then decapsulated to its native form. The Inner.MacDA 
and Data Label are looked up in RBn’s local forwarding tables, and 
one of the three following cases will occur. RBn uses the first case 
that applies and ignores the remaining Cases: 


o 


6.2.2. 


If the destination end station identified by the Inner.MacDA and 
Data Label is on a local link, the native frame is sent onto that 
link with the VLAN from the Inner.VLAN or VLAN corresponding to 
the Inner.Label if the packet is FGL. 


Else if RBn can reach the destination through another member 
RBridge (say RBk), it tunnels the native frame to RBk by 
re-encapsulating it into a unicast TRILL Data packet and sends it 
to RBk. RBn uses RBk's regular nickname instead of the 
pseudo-nickname as the egress nickname for the re-encapsulation, 
and the ingress nickname remains unchanged (somewhat similar to 
Section 2.4.2.1 of [RFC7780]). If the Hop Count value of the 
packet is too small for it to reach RBk safely, RBn SHOULD 
increase that value properly in doing the re-encapsulation. 

(NOTE: When receiving that re-encapsulated TRILL Data packet, as 
the egress nickname of the packet is RBk’s regular nickname rather 
than the pseudo-nickname of a local RBv, RBk will process it per 
Section 4.6.2.4 of [RFC6325] and will not re-forward it to another 
RBridge.) 


Else, RBn does not know how to reach the destination; it sends the 
native frame out of all the local ports on which it is Appointed 
Forwarder for the Inner.VLAN (or Appointed Forwarder for the VLAN 
into which the Inner.Label maps on that port for an FGL TRILL Data 
packet [RFC7172]). 


Multi-Destination TRILL Data Packets 


When RB1 receives a multi-destination TRILL Data Packet, it checks 
and processes the packet as described in Section 4.6.2.5 of 
[RFC6325], with the following exception: 


o 


Zhai, 


On each RBv port where RBn is the Appointed Forwarder for the 
packet’s Inner.VLAN (or for the VLAN to which the packet's 
Inner.Label maps on that port if it is an FGL TRILL Data packet), 
the DF check (see Section 5.2) and the ingress nickname filtering 
check (see Section 5.3) are further performed. For such an RBv 
port, if either the DF check or the filtering check fails, the 
frame MUST NOT be egressed out of that port. Otherwise, it can be 
egressed out of that port. 
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7. 


MAC Information Synchronization in Edge Group 


An edge RBridge, say RBl in LAALP1, may have learned a correspondence 
between a {Data Label and MAC address} and nickname for a remote host 
(say h1) when hl sends a packet to CEl. The returning traffic from 
CEl may go to another member RBridge of LAALP1 (for example, RB2). 
RB2 may not have that correspondence stored. Therefore, it has to do 
the flooding for unknown unicast. Such flooding is unnecessary, 
since the returning traffic is almost always expected and RB1 had 
learned the address correspondence. To avoid the unnecessary 
flooding, RB1 SHOULD share the correspondence with other RBridges of 
LAALP1. RB1 synchronizes the correspondence by using the 
MAC-Reachability (MAC-RI) sub-TLV [RFC6165] in its ESADI-LSPs 
[RFC7357]. 


On the other hand, RB2 has learned the MAC address and Data Label of 
CE1 when CE1 sends a frame to hl through RB2. The returning traffic 
from hl may go to RB1. RB1 may not have CEl's MAC address and Data 
Label stored even though it is in the same LAALP for CEl as RB2. 
Therefore, it has to flood the traffic out of all its access ports 
where it is Appointed Forwarder for the VLAN (see Section 6.2.1) or 
the VLAN the FGL maps to on that port if the packet is FGL. Such 
flooding is unnecessary, since the returning traffic is almost always 
expected and RB2 had learned CE1’s MAC and Data Label information. 

To avoid that unnecessary flooding, RB2 SHOULD share the MAC address 
and Data Label with other RBridges of LAALP1. RB2 synchronizes the 
MAC address and Data Label by enclosing the relative MAC-RI TLV 
within a pair of boundary TRILL APPsub-TLVs for LAALP1 (see 

Section 9.3) in its ESADI-LSP [RFC7357]. After receiving the 
enclosed MAC-RI TLVs, the member RBridges of LAALP1 (i.e., LAALP1 
related RBridges) treat the MAC address and Data Label as if it were 
learned by them locally on their member port of LAALP1; the LAALP1 
unrelated RBridges just ignore LAALP1’s boundary APPsub-TLVs and 
treat the MAC address and Data Label as specified in [RFC7357]. 
Furthermore, in order to make the LAALP1 unrelated RBridges know that 
the MAC and Data Label are reachable through the RBv that provides 
service to LAALP1, the Topology-ID/Nickname field of the MAC-RI TLV 
SHOULD carry the pseudo-nickname of the RBv, rather than a zero value 
or one of the originating RBridge’s (i.e., RB2’s) regular nicknames. 
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8. 


Member Link Failure in an RBv 


As shown in Figure 4, suppose that the link RB1-CEl fails. Although 
a new RBv will be formed by RB2 and RB3 to provide active-active 
service for LAALP1 (see Section 5), the unicast traffic to CEl might 
still be forwarded to RB1 before the remote RBridge learns that CE1 
is attached to the new RBv. That traffic might be disrupted by the 
link failure. Section 8.1 discusses failure protection in this 
scenario. 


However, multi-destination TRILL Data packets can reach all member 
RBridges of the new RBv and be egressed to CEl by either RB2 or RB3 
(i.e., the new DF for the traffic’s Inner.VLAN or the VLAN the 
packet's Inner.Label maps to in the new RBv). Although there might 
be a transient hang time between failure and the establishment of the 
new RBv, special actions to protect against downlink failure for such 
multi-destination packets are not needed. 


/ \ 
| TRILL Campus | 
\ / 
| | | 
+---+ | +----+ 
| | | 
4+------ + 4+------ + 4+------ + 
| RB1 RB2 RB3 
0000000 | DO000 | 000000 | 000 | OOO00 
CA + RBY +t=====- + kueni o+ 
o | 0000 |0000000 | 0000 | oo000 | o0 |o 
heel | +-|-----+ | 
\ | /+-- | ------- + | +------ + | 
- B 4+---------- |------ + 
AN, +----------- + | 
(| | |)<--LAALP1 (| | |)<--LAALP2 
4+------- + 4+------- + 
h GET. | | CE2 | 
4+------- + 4+------- + 


B - Failed Link or Link Bundle 


Figure 4: A Multi-Homed CE with a Failed Link 
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8.1. Link Protection for Unicast Frame Egressing 


When the link CEl-RB1 fails, RB1 loses its direct connection to CEl. 
The MAC entry through the failed link to CEl is removed from RB1's 
local forwarding table immediately. Another MAC entry learned from 
another member RBridge of LAALP1 (for example, RB2, since it is still 
a member RBridge of LAALP1) is installed into RB1’s forwarding table 
(see Section 9.3). In that new entry, RB2 (identified by one of its 
regular nicknames) is the egress RBridge for CE1’s MAC address. 

Then, when a TRILL Data packet to CEl is delivered to RB1, it can be 
tunneled to RB2 after being re-encapsulated (the ingress nickname 
remains unchanged and the egress nickname is replaced by RB2's 
regular nickname) based on the above installed MAC entry (see 

bullet 2 in Section 6.2.1). RB2 then receives the frame and egresses 
it to CEl. 


After failure recovery, RB1 learns that it can reach CEl via link 
CE1-RB1 again by observing CEl's native frames or from the MAC 
information synchronization by member RBridge(s) of LAALP1 as 
described in Section 7. It then restores the MAC entry to its 
previous one and downloads it to its data-plane "fast path" logic. 


9. TLV Extensions for Edge RBridge Group 


The following subsections specify the APPsub-TLVs needed to support 
pseudo-nickname edge groups. 


9.1. PN-LAALP-Membership APPsub-TLV 


This APPsub-TLV is used by an edge RBridge to announce its associated 


pseudo-nickname LAALP information. It is defined as a sub-TLV of the 
TRILL GENINFO TLV [RFC7357] and is distributed in E-L1FS FS-LSPs 
[RFC7780]. It has the following format: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type = PN-LAALP-Membership | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Length | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 

| LAALP RECORD (1) | (variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+—+ 
| LAALP RECORD (n) | (variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 


Figure 5: PN-LAALP-Membership Advertisement APPsub-TLV 
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where each LAALP RECORD has the following form: 


o 


0123456789012345678 
+--+-+-+-+-+-+-+-+ 


| OE | RESV | (1 byte) 
+--+-+-+-+-+-+-+-+ 

| size | (1 byte) 
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Reusing Pseudo-Nickname | (2 bytes) 
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+ 

| LAALP ID | (variable) 
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 


PN-LAALP-Membership (2 bytes): Defines the type of this 
sub-TLV, 2. 


Length (2 bytes): The sum of the lengths of the LAALP RECORDs. 


OE (1 bit): A flag indicating whether or not the LAALP wants to 
occupy an RBv by itself; 1 for occupying by itself (or Occupying 


Exclusively (OE)). By default, it is set to 0 on transmit. This 
bit is used for edge RBridge group auto-discovery (see 
Section 4.1). For any one LAALP, the values of this flag might 


conflict in the LSPs advertised by different member RBridges of 
that LAALP. In that case, the flag for that LAALP is considered 
to be 1. 


RESV (7 bits): MUST be transmitted as zero and ignored on receipt. 


Size (1 byte): Size of the remaining part of the LAALP RECORD 
(2 plus the length of the LAALP ID). 


Reusing Pseudo-Nickname (2 bytes): Suggested pseudo-nickname of 
the AAE group serving the LAALP. If the LAALP is not served by 
any AAE group, this field MUST be set to zero. It is used by the 
originating RBridge to help the vDRB to reuse the previous 
pseudo-nickname of an AAE group (see Section 4.2). 


LAALP ID (variable): The ID of the LAALP. See Section 9.4. 


On receipt of such an APPsub-TLV, if RBn is not an LAALP related edge 
RBridge, it ignores the sub-TLV; otherwise, it parses the sub-TLV. 
When new LAALPs are found or old ones are withdrawn compared to its 
old copy, and they are also configured on RBn, RBn performs the 
"Member RBridges Auto-Discovery" procedure described in Section 4. 
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9.2. PN-RBv APPsub-TLV 


The PN-RBv APPsub-TLV is used by a Designated RBridge of a virtual 
RBridge (vDRB) to dictate the pseudo-nickname for the LAALPs served 
by the RBv. It is defined as a sub-TLV of the TRILL GENINFO TLV 
[REC7357] and is distributed in E-L1FS FS-LSPs [RFC7780]. It has the 
following format: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type = PN-RBv | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Length | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| RBv’s Pseudo-Nickname | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| LAALP ID Size | (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. .. +-+ 

| LAALP ID (1) | (variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. .. +-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+ 
| LAALP ID (n) | (variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+ 


o PN-RBv (2 bytes): Defines the type of this sub-TLV, 3. 


o Length (2 bytes): 3+n*k bytes, where there are n LAALP IDs, each 
of size k bytes. k is found in the LAALP ID Size field below. If 
Length is not 3 plus an integer times k, the sub-TLV is corrupt 
and MUST be ignored. 


o RBv’s Pseudo-Nickname (2 bytes): The appointed pseudo-nickname for 
the RBv that serves the LAALPs listed in the following fields. 


o LAALP ID Size (1 byte): The size of each of the following LAALP 
IDs in this sub-TLV. 8 if the LAALPs listed are MC-LAGs or DRNI 
(Section 6.3.2 of [802.1AX]). The value in this field is the k 
value that appears in the formula for Length above. 


o LAALP ID (LAALP ID Size bytes): The ID of the LAALP. See 
Section 9.4. 


This sub-TLV may occur multiple times with the same RBv 
pseudo-nickname; this means that all of the LAALPs listed are 
identified by that pseudo-nickname. For example, if there are 

LAALP IDs of different length, then the LAALP IDs of each size would 
have to be listed in a separate sub-TLV. 
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Because a PN-RBv APPsub-TLV is distributed as part of the application 
link state by using the E-L1FS FS-LSP [RFC7780], creation, changes to 
contents, or withdrawal of a PN-RBv APPsub-TLV is accomplished by the 
Designated RBridge updating and flooding an E-L1FS PDU. 


On receipt of such a sub-TLV, if RBn is not an LAALP related edge 
RBridge, it ignores the sub-TLV. Otherwise, if RBn is also a member 
RBridge of the RBv identified by the list of LAALPs, it associates 
the pseudo-nickname with the ports of these LAALPs and downloads the 
association to data-plane fast path logic. At the same time, RBn 
claims the RBv’s pseudo-nickname across the campus and announces the 
RBv as its child on the corresponding tree or trees using the 
Affinity sub-TLV [RFC7176] [RFC7783]. 


9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs 


In this document, two APPsub-TLVs are used as boundary APPsub-TLVs 
for an edge RBridge to enclose the MAC-RI TLV(s) containing the MAC 
address information learned from the local port of an LAALP when this 
RBridge wants to share the information with other edge RBridges. 

They are defined as TRILL APPsub-TLVs [RFC7357]. The 
PN-MAC-RI-LAALP-INFO-START APPsub-TLV has the following format: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type=PN-MAC-RI-LAALP-INFO-START| (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Length | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+ 

| LAALP ID | (variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+ 


o PN-MAC-RI-LAALP-INFO-START (2 bytes): Defines the type of this 
sub-TLV, 4. 


o Length (2 bytes): The size of the following LAALP ID. 8 if the 
LAALP listed is an MC-LAG or DRNI. 


o LAALP ID (variable): The ID of the LAALP (see Section 9.4). 
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The PN-MAC-RI-LAALP-INFO-END APPsub-TLV is defined as follows: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type=PN-MAC-RI-LAALP-INFO-END | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Length | (2 bytes) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


o PN-MAC-RI-LAALP-INFO-END (2 bytes): Defines the type of this 
sub-TLV, 5. 


o Length (2 bytes): 0. 


This pair of APPsub-TLVs can be carried multiple times in an 
ESADI-LSP and in multiple ESADI-LSPs. When an LAALP related edge 
RBridge (say RBn) wants to share with other edge RBridges the MAC 
addresses learned on its local ports of different LAALPs, it uses one 
or more pairs of such APPsub-TLVs for each such LAALP in its 
ESADI-LSPs. Each encloses the MAC-RI TLVs containing the MAC 
addresses learned from a specific LAALP. Furthermore, if the LAALP 
is served by a local RBv, the value of the Topology-ID/Nickname field 
in the relative MAC-RI TLVs SHOULD be the pseudo-nickname of the RBv, 
rather than one of RBn’s regular nicknames or a zero value. Then, on 
receipt of such a MAC-RI TLV, remote RBridges know that the contained 
MAC addresses are reachable through the RBv. 


On receipt of such boundary APPsub-TLVs, when the edge RBridge is not 
an LAALP related one or cannot recognize such sub-TLVs, it ignores 
them and continues to parse the enclosed MAC-RI TLVs per [RFC7357]. 
Otherwise, the recipient parses the boundary APPsub-TLVs. The 
PN-MAC-RI-LAALP-INFO-START / PN-MAC-RI-LAALP-INFO-END pair MUST occur 
within one TRILL GENINFO TLV. If an END is encountered without any 
previous START in the ESADI-LSP, the END APPsub-TLV is ignored. 

After encountering a START, if the end of the ESADI-LSP is reached 
without encountering an END, then the end of the ESADI-LSP is treated 
as if it were a PN-MAC-RI-LAALP-INFO-END. The boundary APPsub-TLVs 
and TLVs between them are handled as follows: 


1) If the edge RBridge is configured with the contained LAALP and the 
LAALP is also enabled locally, it treats all the MAC addresses 
contained in the following MC-RI TLVs enclosed by the 
corresponding pair of boundary APPsub-TLVs as if they were learned 
from its local port of that LAALP; 


2) Else, it ignores these boundary APPsub-TLVs and continues to parse 


the following MAC-RI TLVs per [RFC7357] until another pair of 
boundary APPsub-TLVs is encountered. 
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9. 


10. 


EIs 


4. LAALP IDs 


The LAALP ID identifies an AAE RBridge group in the TRILL campus and 
thus MUST be unique across the campus. In all of the APPsub-TLVs 
specified above, the length of the LAALP ID can be determined from a 
size field. If that length is 8 bytes, the LAALP ID is an MC-LAG or 
DRNI identifier as specified in Section 6.3.2 of [802.1AX]. The 
meaning and structure of LAALP IDs of other lengths are reserved and 
may be specified in future documents. 


OAM Packets 


Attention must be paid when generating Operations, Administration, 
and Maintenance (OAM) packets. To ensure that the response messages 
can return to the originating member RBridge of an RBv, a 
pseudo-nickname cannot be used as the ingress nickname in TRILL OAM 
messages, except in the response to an OAM message that has that 
RBv’s pseudo-nickname as the egress nickname. For example, assume 
that RB1 is a member RBridge of RBvi.  RB1 cannot use RBvi's 
pseudo-nickname as the ingress nickname when originating OAM 
messages; otherwise, the responses to the messages may be delivered 
to another member RBridge of RBvi rather than RB1. But when RB1 
responds to the OAM message with RBvi's pseudo-nickname as the egress 
nickname, it can use that pseudo-nickname as the ingress nickname in 
the response message. 


Since RBridges cannot use OAM messages for the learning of MAC 
addresses (Section 3.2.1 of [RFC7174]), it will not lead to MAC 
address flip-flopping at a remote RBridge, even though RB1 uses its 
regular nicknames as ingress nicknames in its TRILL OAM messages, and 
at the same time RB1 uses RBvi's pseudo-nickname in its TRILL Data 
packets. 


Configuration Consistency 


The VLAN membership of all the RBridge ports in an LAALP MUST be the 
same. Any inconsistencies in VLAN membership may result in packet 
loss or non-shortest paths. 


Take Figure 1 as an example. Suppose that RB1 configures VLAN1 and 
VLAN2 for the CE1-RB1 link, while RB2 only configures VLAN1 for the 
CE1-RB2 link. Both RBl and RB2 use the same ingress nickname RBv for 
all frames originating from CE1. Hence, a remote RBridge (say RBx) 
will learn that CEl's MAC address in VLAN2 is originating from the 
RBv. As a result, on the return path, RBx may deliver VLAN2 traffic 
to RB2. However, RB2 does not have VLAN2 configured on the CE1-RB2 
link, and hence the frame may be dropped or has to be redirected to 
RB1 if RB2 knows that RB1 can reach CEl in VLAN2. 
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12: 


How LAALP implementations maintain consistent VLAN configuration on 
the TRILL switch LAALP ports is out of scope for the TRILL protocol. 
However, considering the consequences that might be caused by 
inconsistencies, TRILL switches MUST disable the ports connected to 
an LAALP with an inconsistent VLAN configuration. 


It is important that if any VLAN in an LAALP is being mapped by edge 
RBridges to an FGL [RFC7172] the mapping MUST be the same for all 
edge RBridge ports in the LAALP. Otherwise, for example, unicast FGL 
TRILL Data packets from remote RBridges may get mapped into different 
VLANs, depending on which edge RBridge receives and egresses them. 


It is important that RBridges in an AAE group not be configured to 
assert the OE-flag if any RBridge in the group does not implement it. 
Since, as stated in [RFC7379], the RBridges in an AAE edge group are 
expected to be from the same vendor, due to the proprietary nature of 
deployed LAALPs, this will normally follow automatically from all of 
the RBridges in an AAE edge group supporting, or not supporting, OE. 


Security Considerations 


Authenticity for contents transported in IS-IS PDUs is enforced using 
regular IS-IS security mechanisms [IS-IS] [RFC5310]. 


For security considerations pertaining to extensions transported by 
TRILL ESADI, see the Security Considerations section in [RFC7357]. 


Since currently deployed LAALPs [RFC7379] are proprietary, security 
over membership in, and internal management of, active-active edge 
groups is proprietary. If authentication is not used, a rogue 
RBridge that insinuates itself into an active-active edge group can 
disrupt end-station traffic flowing into or out of that group. For 
example, if there are N RBridges in the group, it could typically 
control 1/Nth of the traffic flowing out of that group anda 
similar amount of unicast traffic flowing into that group. For 
multi-destination traffic flowing into that group, it could control 
all that was in a VLAN for which it was the DF and can exercise 
substantial control over the DF election by changing its own 

System ID. 


For general TRILL security considerations, see [RFC6325]. 
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13. IANA Considerations 


IANA has allocated four code points from the range below 255 for the 
four TRILL APPsub-TLVs specified in Section 9 and added them to the 
"TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" 


registry, as follows: 
Type Name Reference 
2 PN-LAALP-Membership REC 7781 
3 PN-RBv REC 7781 
4 PN-MAC-RI-LAALP-INFO-START RFC 7781 
5 PN-MAC-RI-LAALP-INFO-END RFC 7781 
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